동적 템플릿 엔진 설계 패턴 (계층화·SpEL·Chain of Responsibility)

NOTE

SI 환경처럼 고객사별 요구사항이 파편화된 상황에서, JSON 템플릿 기반 데이터 생성 도구를 점진적으로 고도화하는 4단계 전략. “Init Data 생성 Tool” 미니프로젝트의 고도화 검토에서 추출. 관련 노트: [(Java) 계층적 스트리밍 파이프라인 설계로 OOM 방지 - 핵심 개념 및 특징 정리](../../../개발 (CS)/언어/JAVA/[Java]%20%EA%B3%84%EC%B8%B5%EC%A0%81%20%EC%8A%A4%ED%8A%B8%EB%A6%AC%EB%B0%8D%20%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8%20%EC%84%A4%EA%B3%84%EB%A1%9C%20OOM%20%EB%B0%A9%EC%A7%80%20-%20%ED%95%B5%EC%8B%AC%20%EA%B0%9C%EB%85%90%20%EB%B0%8F%20%ED%8A%B9%EC%A7%95%20%EC%A0%95%EB%A6%AC.md) — 같은 도구의 메모리 구조 고도화

⚙️ 개념 — 왜 점진적 고도화가 필요한가

스트림 방식으로 메모리 효율을 확보하고 전략 패턴으로 확장성을 확보한 코어 엔진을 기반으로, 고객사별로 기능이 추가·제외되는 유동적인 상황을 해결하기 위한 4단계 전략.

⚙️ Step 1 — 템플릿 계층화 (Template Hierarchy & Overriding)

테이블별로 JSON 템플릿을 관리하면 고객사가 늘어날수록 JSON 파일이 기하급수적으로 늘어난다. 이를 방지하기 위해:

• Base & Custom 분리: 모든 고객사가 공통으로 가지는 표준 템플릿(Base)과 고객사별 요구사항이 담긴 커스텀 템플릿(Custom)으로 분리
• JSON 병합(Merge) 로직: 툴이 실행될 때 고객사 식별자를 입력받아, Base JSON을 먼저 로드하고 Custom JSON으로 덮어쓰기(Deep Merge) 수행
• 효과: 기능이 빠진 고객사는 특정 컬럼을 null/빈 값으로 덮어쓰고, 추가된 고객사는 새로운 key-value만 Custom JSON에 작성하면 되므로 유지보수가 쉬워짐

⚙️ Step 2 — 표현식 엔진(Expression Engine) 도입

동적으로 바뀌는 데이터를 메모리 컨텍스트에 올려 리졸버로 처리하는 방식에서 한 단계 더 나아가, JSON 템플릿 자체에 논리 연산을 부여한다.

• SpEL(Spring Expression Language) 활용: JSON 템플릿 내부에 SpEL 문법을 직접 작성하고 툴에서 이를 평가(Evaluate)
  • 예시: "auth_status": "#{featureFlags.useApproval ? 'WAITING' : 'APPROVED'}"
• 효과: 자잘한 조건 분기 로직을 리졸버의 Java 코드 레벨에서 처리할 필요 없이, 템플릿 레벨에서 컨텍스트 데이터를 참조해 즉시 결정 가능. 리졸버의 복잡도를 크게 낮춤

⚙️ Step 3 — 리졸버(Resolver)의 파이프라인화 (Chain of Responsibility)

고객사별로 완전히 새로운 비즈니스 로직(데이터 가공 로직)이 들어가야 할 때 기존 전략 패턴의 인터페이스가 무거워질 수 있다.

• 단일 리졸버 → 체인으로: 하나의 템플릿에 하나의 리졸버가 매핑되는 구조에서, 여러 리졸버가 순차적으로 실행되는 파이프라인 구조(Chain of Responsibility 패턴)로 변경
• 동적 주입: 실행 시점에 고객사 Context를 읽어, [공통 암호화 리졸버] → [A고객사 전용 포맷팅 리졸버] → [공통 DB 매핑 리졸버] 순으로 필요한 리졸버들만 조립해 스트림에 태움
• 효과: 기존 코드를 전혀 수정하지 않고, 새로운 고객사용 리졸버 클래스만 추가하여 파이프라인에 끼워 넣으면 되므로 OCP(개방-폐쇄 원칙)를 준수

⚙️ Step 4 — 메타데이터 기반의 스키마 검증 (Schema Validation)

SI 환경에서는 고객사별로 실제 데이터베이스 스키마가 미세하게(컬럼 추가/삭제 등) 달라지는 경우가 많다.

• 사전 검증 단계 추가: 스트림으로 데이터를 밀어 넣기 전에, 병합이 완료된 최종 JSON 템플릿 구조와 타겟 데이터베이스의 테이블 스키마 메타데이터를 비교
• 효과: 고객사 A에는 없는 컬럼에 데이터를 넣으려다 발생하는 런타임 SQL 에러를, 툴 실행 극초반에 감지하고 차단 가능

🔁 우선순위

가장 가성비가 좋은 것은 **Step 1(JSON 템플릿 병합)**이나 **Step 2(SpEL 등 표현식 도입)**를 먼저 적용해 JSON 파일의 관리 복잡도를 낮추는 것이다.